Method and system for transferring data between a discrete event environment and an external environment

ABSTRACT

The present invention provides systems and methods for transfer of information between various modeling environments in a model of a system. In one embodiment, a system and method for transferring data between a discrete event model environment and an external model environment other than a discrete event environment is provided.

RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication Ser. No. 60/611,571, filed Sep. 20, 2004 for all subjectmatter common to both applications. The disclosure of theabove-mentioned application is hereby incorporated by reference hereinin their entirety.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the transferring of data from aDiscrete Event modeling environment to other modeling environments, aswell as the transfer of data from a non-discrete event modelingenvironment to a discrete event modeling environment. Data transferredbetween a Discrete Event modeling environment and another modelingenvironment must take into account the timing and data managementdifferences between various modeling environments such that data can beimported, exported, or both in a useable manner.

BACKGROUND

Generally, graphical analysis, simulation, and execution methods areused in modeling, design, analysis, and synthesis of engineered systems.These methods provide a visual representation of a model, such as ablock diagram. The visual representation provides a convenientinterpretation of model components and structure. The visualrepresentation also provides a quick intuitive notion of systembehavior. The components of a block diagram can also capture themathematical representation of the actual system being modeled.

Historically, time-based block diagram models have been used inscientific areas, such as Feedback Control Theory and Signal Processing.Time-based block diagrams are used to study, design, debug, and refinedynamic systems representative of many real-world systems. A dynamicsystem (either natural or man-made) is a system whose response at anygiven time is a function of its input stimuli, its current state, andthe current time. Such systems range from simple to highly complexsystems. Physical dynamic systems include a falling body, the rotationof the earth, bio-mechanical systems (muscles, joints, etc.),bio-chemical systems (gene expression, protein pathways), weather andclimate pattern systems, etc. Examples of man-made or engineered dynamicsystems include: a bouncing ball, a spring with a mass tied on an end,automobiles, airplanes, control systems in major appliances,communication networks, audio signal processing, nuclear reactors, astock market, and the like.

Professionals from diverse areas such as engineering, science,education, and economics build mathematical models of dynamic systems tobetter understand system behavior as it changes with the progression oftime. The mathematical models aid in building better systems, which canbe defined in terms of a variety of performance measures such asquality, time-to-market, cost, speed, size, power consumption,robustness, etc. The mathematical models also aid in analyzing,debugging and repairing existing systems (be it the human body or theanti-lock braking system in a car). The models may serve to educateusers on the basic principles governing physical systems. The models andresults are often used as a scientific communication medium betweenhumans. The term “model-based design” refers to the use of models, oftengraphical, in the analysis, development, validation, and operation ofdynamic systems.

Dynamic systems are typically modeled in modeling environments as setsof differential, difference, and/or algebraic equations. At any giveninstant of time, these equations may be viewed as relationships betweenthe system's output response (“outputs”), the system's input stimuli(“inputs”) at that time, the current state of the system, the systemparameters, and time.

Time-based block diagram modeling has become particularly attractiveover the last few years with the advent of software packages to processlarge amounts of data and perform a high number of computationaliterations. In fact, various classes of graphical models enable a userto describe a system and related computations that can be performed onapplication specific computational hardware, such as a computer,microcontroller, FPGA, or custom hardware. Classes of such graphicalmodels include time-based block diagram execution applications such asSimulink® from the MathWorks, Inc. Natick Mass., and state-based flowdiagram execution applications such as Stateflow® from the MathWorks,Inc. Natick Mass., in addition to other models such as data flowdiagrams, Unified Modeling Language (UML) models, VHDL models, analogextension models, and the like.

A common characteristic among these various forms of model executionapplications is that they define semantics of how to execute the modeldiagram, and thus they specify how to model a dynamic system. Suchapplications provide sophisticated software platforms with a rich suiteof support tools that make the analysis and design of dynamic systemsefficient, methodical, and cost-effective. Furthermore, suchapplications can support the modeling of linear and nonlinear systems.These systems may be modeled in continuous time, sampled (or discrete)time, or a hybrid of continuous and discrete time. Systems can also bemultirate, i.e., have different parts that are sampled or updated atdifferent rates.

Time can be an inherited component of model diagram executionapplications in that the results of a model diagram execution aredependent on time and as such, vary with time. In other words, a modeldiagram execution or model represents the instantaneous behavior of adynamic system and models that system over time. Determining a system'sbehavior over time requires repeatedly executing a model of the systemat intervals, called time steps, from the start of the time span to theend of the time span.

Systems may be categorized by the type of time step being used(fixed-step or variable-step). A fixed-step system is one that uses afixed-step solver. A variable-step system is one that uses avariable-step solver. A solver is a module of the execution engine thatis responsible for performing two tasks: (1) determining how farexecution time should be advanced between consecutive passes through asystem in order to accurately trace the system's outputs, and (2)integrating the derivative of the states of the system to obtain theactual states. Based on how solvers perform the first task, they aregenerally classified into two basic classes: Fixed-step solvers orVariable-step solvers. Fixed-step solvers often use explicit methods tocompute the next continuous state at fixed periodic intervals of time. Avariable-step solver can use either implicit or explicit methods tocompute the next continuous state at non-periodic intervals of time.Generally, variable-step solvers use a form of error control to adjustthe interval size such that the desired error tolerances are achieved.

Solvers can also be categorized into two classes with respect to time:continuous-time solvers and discrete-time solvers. Continuous-timesolvers use numerical integration to compute a model's continuous statesat the current time step from the states at previous time steps and thestate derivatives. Continuous-time solvers rely on the model's blocks tocompute the values of the model's discrete states at each time step.Mathematicians have developed a wide variety of numerical integrationtechniques for solving the ordinary differential equations (ODEs) thatrepresent the continuous states of dynamic systems. Continuous-timesolvers can further be separated into fixed-step continuous-time solversand variable-step continuous-time solver. Discrete-time solvers existprimarily to solve purely discrete models. They compute the nextexecution time step for a model and nothing else. Discrete-time solversdo not compute continuous states and they rely on the model's blocks toupdate the model's discrete states. Similarly, discrete-time solvers canalso be further separated into fixed-step discrete-time solvers andvariable-step discrete-time solvers.

Simulink® is an example of an interactive graphical modeling tool thatenables users to quickly create, model, simulate, and test block diagramrepresentations of dynamic systems. Simulink® uses time-dependentmodels. It is suitable for simulating time-varying systems. FIG. 1 showsan example of a Simulink® model. The Simulink® model makes use of blocksand arrows to connect the blocks, when forming the model. Each arrowconnecting one enabled block to another represents a signal having avalue at all times. The arrow indicates which blocks read from thesignal and write to the signal as the signal varies with time.

In time-based models, in order to know what happens with the system at aspecific time in the future (such as at time equals 1000 seconds) themodel must be initiated at a time of n seconds, where n is less than1000 and the behavior at time n is known, and stepped through time toarrive at the 1000 second mark. For example, the model can be executedas follows in accordance with one example implementation embodiment.Input signal 100 generates an input signal. Link 114 connects the signalfrom the Integrator block 104 as determined by the state of theIntegrator block 104 to a Scope block 108 for display, and also connectsthe signal to Gain block 106 through 114. At execution start time, thestate of the Integrator block 104 has a user-defined initial value or adefault initial value. Gain block 106 performs calculation on the inputsignal from link 114 and outputs the result on link 116 that connects tothe Sum block 102. Sum block 102 adds the signal from link 110 and link116 and outputs the result in the form of link 112. Integrator block 104takes the signal from link 112 and performs integration on the inputsignal and updates its state accordingly. The model continues onoperating on the updated state until a predetermined condition isachieved, a time period is attained, or the user interrupts theexecution.

Dynamic systems can also be modeled from a state-based perspective. Thestate of the system may be thought of as a symbolic representation ofthe dynamically changing configuration of the system. For instance, in amodel of a perfect nonelastic collision between two bodies, the statemay be viewed as either the configuration where the two bodies areseparated or the configuration where they are in contact. The systemparameters are the numerical representation of the static, orunchanging, configuration of the system and may be viewed as constantcoefficients in the equations modeling the system. For the nonelasticcollision example, a parameter is the mass of one of the bodies.

Stateflow® is an example of a state-based dynamic system modelingapplication. Stateflow® is configured as a tool in Simulink® that can beused to design embedded systems that contain control, supervisory, ormode logic. By using Stateflow® with Simulink®, users can create modelsthat combine state transition behavior (for example, fault detection ormode switching) with algorithmic continuous-time and discrete-timebehavior (for example, feedback control or signal conditioning). Userscan also create a model of the system and its environment in Simulink®and run hybrid executions to study the interactions between the two.

In Simulink®D, a Stateflow® block uses a state transition diagram torepresent an object with a discrete set of modes. These modes are knownas states. A Stateflow® chart is a graphical representation of a finitestate machine where states and transitions form the basic buildingblocks of the system. Stateflow® charts enable the graphicalrepresentation of hierarchical and parallel states and the event-driventransitions between them. The Stateflow® finite state machine reacts toevents by changing states for the controlled object. A controlled objectcan be a motor, a pump, or any device that changes its behavior inresponse to external stimuli. The behavior of the object depends on whatstate the object is in and how the object changes from one state toanother.

In the specific example application Stateflow®, the modeling process formodeling state-based executions, is embedded in Simulink®. Thus, theexecution is invoked by Simulink® or some other time based dynamicmodeling application, and does not run independently. In the case ofStateflow®, as execution starts, Simulink® starts its clock. When theexecution engine reaches a Stateflow® block, the Simulink® clock stopsevolving, and the execution engine passes information to Stateflow®, andawaits a signal back from Stateflow®. Stateflow® then performs itsstate-based modeling process. Once all the Stateflow® blocks finishtheir execution, outputs are sent to Simulink®, and the Simulink® clockstarts ticking again. Therefore, during the execution of Stateflow®blocks, the execution is instantaneous, i.e., has no time effect on theSimulink® model. All the events and state transitions that occur inStateflow® are considered to have taken place at the specific moment intime when the clock stops.

An example of a Stateflow® form of a state diagram model is shown inFIG. 2. Each arrow in the Stateflow® diagram also has values like theSimulink® arrows, but these values represent a decision value relatinginformation that can cause one state to transition to another. Thearrows in Stateflow® indicate the direction of the state transition. Theexemplar Stateflow® diagram as shown in FIG. 2 is embedded in aSimulink® environment as shown in FIG. 3. The Simulink® signals areprovided to Stateflow®, and Stateflow® uses this information to decidewhether there are changes in states.

More specifically, in operation, a state flowchart 136 diagram is shownin FIG. 2, which corresponds to a detailed description of the flowchart136 shown in FIG. 3. In FIG. 3, port data temp 158 receives a signalfrom the output of physical plant 146. Port temp_min 156 receives avalue from a constant block 144 in Simulink® as the minimum set pointtemperature for the physical plant. Data switch 150 receives data fromSimulink® constant block 140 or 142 indicating whether the switch shouldbe on or off. Output port speed 160 on the stateflowchart is thencalculated based on input values 154, 156, and 158. Physical plant 146receives data from output port speed 160 for further calculations withinthe physical plant 146. Within the state flowchart 136 as shown in FIG.2, there are two states: an on state 120 and an off state 122. Thedefault transition 126 determines that the initial state is the offstate 122. When an on_switch transition 130 is enabled, the enabletransition passes to junction 124 and determines whether the temp 158data is greater or equal to 30, if not, then the enable transition ispassed on to transition 132 and further finish the transition to the onstate 120. Now the on state 120 is active and off state 122 inactive.The off state 122 will become active again when the off_switchtransition 128 is enabled, at which time the on state 120 will becomeinactive.

One notable difference between Simulink® (and similar dynamic modelingprograms) and Stateflow® (and similar state modeling programs) is thatStateflow® models state changes in response to discrete events and isimplemented within the time-driven environment, whereas Simulink® ismodeled in continuous time or discrete time and is the time-drivenenvironment. Said differently, Simulink® is a time-driven engine andStateflow® is an event-driven engine embedded and initiated in atime-driven environment.

Dynamic systems are typically modeled in execution environments as setsof equations. At any given instant of time, the equations output valuesthat can be considered states, and can also be communicated to stateflow modelers. Thus, users conventionally have the ability to modelusing time-driven equations, and/or event-driven models controlled bytime-driven equations. For example, if a user wants to know how fast aschool bus is traveling at a specific moment in time, the user can useSimulink® to model the speed of the school bus. If part of thedetermination of the speed is what gear the school bus transmission isin, the gear indication can be modeled in Stateflow® within theSimulink® speed model.

Stateflow®, and similar state modeling applications, are thereforeutilized when the location and exact behavior of objects are notimportant but actions taken or completed on or by the objects are ofinterest. Such state flowchart models are currently invoked by the timedriven dynamic modeling environments, such as that of Simulink®. Hence,if only a small number of Stateflow® calls are made by Simulink®, delayscan be practically non-noticeable.

However, returning to the school bus example, if the user wants to knowin the event of an emergency how fast the school children can get offthe school bus, then the user must attempt a highly complex combinationof time-driven equations and embedded event-driven models in time-drivenenvironments to approximate the movement of each child off the bus. InSimulink®, such a model will also track the exact position of eachchild, despite the fact that whether a child has progressed onecentimeter forward is not the focus of such a model. Regardless, suchinformation must be tracked in the time dependent graphical model. Also,in such a model, the clock time that each child leaves the bus isunimportant. However, the number of children getting off the bus, theintervals between each child getting off the bus, and the position ofthe child as either remaining on the bus or being safely off the bus,are what is desired to be modeled. Such events are highly complex tomodel in time-driven model executions and state-based model executionsoperating in time-driven environments.

Furthermore, if a user wants to model network traffic and to determinehow fast a router can relay millions of packets, it is computationallycostly to use the state flowchart model within the dynamic block diagramtime driven environment because such a configurations require constantcalls between programs. Hence, the delay in execution output can be verynoticeable, and can even approach the hardware processing limitationsand bog down an execution to the point of ineffectiveness.

Accordingly, a modeling application that is event driven, and does notrequire a continuous time operation to execute, is desired.

SUMMARY OF THE INVENTION

The present invention generally relates to the transfer of informationbetween various modeling environments in a model of a system, and moreparticularly relates to the transfer of data between a discrete eventmodel environment and an external model environment other than adiscrete event model environment.

In accordance with a first aspect of the present invention, a method oftransferring data between a plurality of environments is provided. Inaccordance with the present embodiment, a first environment is providedwherein the first environment is an event driven discrete event modelenvironment. This event driven discrete event model contains at leastone entity that passes through said model. Additionally a distinctsecond environment distinct from the first environment is furtherprovided. Furthermore, in accordance with the present embodiment, agateway interface is implemented, such that said interface modifies datacompatible with the discrete event model environment such that it iscompatible with the second environment.

In accordance with an alternate embodiment, a system for transferringdata between a plurality of model environments is recited. The systemincludes a first discrete event environment, and a second environmentdistinct from the first discrete event environment. Additionally, agateway interface is provided wherein the gateway interface is incommunication with the first environment and the second environment suchthat data can be transferred between the two environments. In variousaspects of the present embodiment, the second environment can be a timebased model environment, a state based model environment, a generalevent-driven model environment, a dataflow based model environment orsome combination thereof.

In accordance with an alternate embodiment of the present invention, aninterface mechanism for transferring data between a discrete event modeland a distinct environment is provided. The interface includes a gatewayblock that is in communication with both the discrete event modelenvironment and the distinct environment. Furthermore the systemincludes a conversion utility associated with the gateway block suchthat the conversion utility produces a compatible signal for use inestablishing communication between the discrete event mode and thedistinct environment

BRIEF DESCRIPTION OF FIGURES

The illustrative embodiment of the present invention will be describedbelow relative to the following drawings.

FIG. 1 is an illustrative embodiment of a Simulink® model for use withthe present invention.

FIG. 2 is an illustrative embodiment of a Stateflow® model for use withthe present invention.

FIG. 3 is a hybrid external environment for use with the presentinvention.

FIG. 4 is an illustrative example of a Discrete Event model environmentfor use with the present invention.

FIG. 5 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 6 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 7 is an illustrative embodiment of a Discrete Event modelenvironment in communication with an external environment.

FIG. 8 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 9 is an illustrative representation of the Event calendar for usewith the present invention.

FIG. 10 is an illustrative embodiment of the event calendar and systemmodel of the present invention.

FIG. 11 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 12 is an illustrative embodiment of the event calendar and systemmodel of the present invention.

FIG. 13 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 14 is an illustrative embodiment of the event calendar and systemmodel of the present invention.

FIG. 15 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 16 is an illustrative embodiment of the event calendar and systemmodel of the present invention.

FIG. 17 is an illustrative embodiment of a Discrete Event modelenvironment.

FIG. 18 is an illustrative embodiment of the event calendar and systemmodel of the present invention.

FIG. 19 is an illustrative embodiment of the event calendar of thepresent invention.

FIG. 20 is an illustrative embodiment of the event calendar of thepresent invention.

FIG. 21 is an illustrative embodiment of the event calendar containingpriority data for use with the present invention.

FIG. 22 is an illustrative view of a block diagram model for use inaccordance with the present invention.

FIG. 23 is an illustrative view of a DES model block for use inaccordance with the present invention.

FIG. 24A is an illustrative view of a DES model block for use inaccordance with the present invention.

FIG. 24B is an illustrative embodiment of DES model of the presentinvention when used with an external invention.

FIG. 24C is a graphical representation of an entity attribute of thepresent invention.

FIG. 24D is a graphical representation of an entity attribute of thepresent invention.

FIG. 25 is an illustrative view of a DES model block for use inaccordance the present invention.

FIG. 26 is an illustrative view of a DES model block for use inaccordance with the present invention.

FIG. 27A is an illustrative view of a DES model for use in accordancewith the present invention.

FIG. 27 B is an illustrative view of a DES model for use in accordancewith the present invention.

FIG. 28 is an alternate embodiment of the present wherein a block isassociated with a plurality of gateway blocks.

FIG. 29 is an illustrative electronic device for use with the presentinvention.

DETAILED DESCRIPTION

Therefore it is desired to provide a modeling environment that can modelthe occurrence of events independent of continuous model time. Adiscrete event system (DES) modeling environment is one wherein thesystem's state transitions depend on asynchronous discrete incidentscalled events. Such a model execution differs greatly from a time basedmodel environment, such as Simulink®, wherein the execution of the modelis time driven.

In reference to FIG. 4, a DES model environment 200 is provided. The DESmodel environment 200 includes an event modeling manager 201. Themanager 201 coordinates the operation of the DES model environment toprocess model executions. The manager 201 includes a solver 203, whichprocesses the DES model configured in the DES model environment 200. Themanager 201 provides for the implementation of the DES model environment200 by supporting the creation of DES blocks 205 that represent variousaspects of the DES model. The blocks 205 can represent differentportions of the model as later described herein. Example blocks includean entity generator, a queue, a server, and a terminator, in addition toother blocks having specific tasks and implementations. A block library207 can be provided that is customized for operation within the DESenvironment. Furthermore, the block library in the present DES modeleris not industry specific, thereby providing for numerous user-definedapplications.

A primary data component within the DES model is referred to as anentity. Entities are abstract representations of areas of interestwithin the DES model and may vary depending upon that which is beingmodeled by the DES system. Entities are the items that pass from blockto block in the DES modeling environment. For example, when modeling adigital network, an entity may represent a data packet. In anotherexample, when modeling a manufacturing plant, entities may take the formof individual items on the assembly line. Each DES model has at leastone entity within the model.

The blocks 205 are interconnected using block connectors that passentities and other information between blocks. The information caninclude information from other models or data sources or references thathave some contribution to the creation or operation of the entities asthey pass through the DES model. The blocks can also have blockconnectors that pass information out to other models or data sourcesoutside of the DES model.

In operation, the DES model environment 200 makes use of the variousblocks to organize and manipulate entities through the DES model. Forexample, the manager 201 manages the configuration of multiple blocks205 to form the DES model. Blocks 205 can be placed in the model forentity generation, subsequent entity manipulation, and eventually entitytermination. The basic operation of the DES model involves passing theentities through the blocks according to instructions governed by themanager 201 and solver 203. The manager 201 can be represented by anevent calendar, wherein the event calendar serves to drive the DES modelforward by executing the next scheduled event in the event calendar. Thesolver 203 in the present invention is a DES specific mechanism whichallows for the execution of events in the DES event calendar in light ofoperations that can occur in the external environment. The solver 203 ofthe present invention, therefore, is in communication with the externalenvironment and can notify the external environment of events within theDES environment which can affect the semantics of the externalenvironment.

Nominally, an entity contains a set of attributes associated with theentity. However, an entity can contain as few as zero attributes. Anattribute can be a field wherein the attribute is named and theattribute type is defined. For example, a field can define the entitytype as a Boolean, a real number, an integer number, an enumerated type,a string, a vector, a matrix, a frame, and the like, such that theentity is of arbitrary data type. An arbitrary data type represents anarbitrarily complex structure containing data that may includehierarchical composition. The contained data can be as general as asingle bit of information and any sequence of such bits representingcharacters, numeric values, or any other syntactic and semantic datum.Furthermore, an entity can contain sub-entities. Sub entities can beutilized in numerous operations such as recursive nesting or combininghierarchies.

The generation of entities can be automatic, or can be user-defined.User-defined entities allow users within a specific industry to definethose attributes that are specific to their needs. The entity can thenbe incorporated into a DES model, thereby providing great userflexibility. Entities can further incorporate randomness into theirbehavior via probability distributions associated with blocks generatingeach entity. These probability distributions can be representative ofthe probability of an entity being generated based upon a set of definedvariables. Probability distribution can be user defined or can begenerated automatically, such that a probability of an event occurringdrives entity generation within the model. Furthermore, the generationof a probability distribution may be accomplished utilizing otherapplications or environments, such as but not limited to the MATLAB®environment or the Simulink® environment.

It should further be noted that there can be a relationship betweenattributes and random numbers as well. When setting attributes ofentities, the user can assign values based on input from separateenvironments, such as Simulink®, to attributes in passing entities. Suchseparate environments can allow the values to be drawn from aprobability distribution. The separate environment thus allows theattributes to be assigned samples from random variables. These randomvalues can be used to introduce randomness in a controlled way to otherparts of the model when they move into those parts of the model.

FIG. 5 depicts a sample DES model environment 200. The present DES modelenvironment includes sources 202 and sinks 208 as depicted in FIG. 5.Sources 202 correspond to those blocks that allow data input into themodel, while sinks 208 correspond to those blocks that remove entitiesfrom the model. A source 202 in a DES model can take numerous forms. Asource 202 can be an entity generator that produces numerous entities atfixed time intervals. Another example of a source 202 is an externaloperating environment outside of the DES model. For clarity, thisexternal operating environment is not shown on FIG. 5. However, as anexample, Simulink® can be used as a source for the present DES modeler,wherein a Simulink signal can trigger the generation of an entity foruse in the DES model based upon criteria set by a DES modeler user.

Sinks 208 in a DES model can have functions other than terminatingentities, such as returning arbitrary values from entities. A DES sink208 can display all of the attributes passed to it, or can display adefined set of variables. Sinks 208 for use in the DES modeler of thepresent invention can also take various forms. One example of a DESmodeler sink 208 is a Terminator Block. The Terminator Block can bedefined to accept all entities delivered to it, or in the alternativecan block all or some entities delivered to it according to selectedconditions. Another example of a possible form of sink 208 in thepresent DES modeler is a Scope Block. The Scope Block can accept anentity and plots data from the entity in a graphical manner. Thisgraphical depiction can allow a user to closely monitor the status ofthe DES model as well as view numerous trends within the modelgraphically. A Display Block can also display selected attributes of anentity. Furthermore, a sink 208 in the present invention can be a blockthat allows the export of a signal from the DES model to an externalenvironment. For example the DES modeler of the present invention caninclude a block that receives an entity and outputs a Simulink® signalthat may be used in a Simulink® environment.

In the present invention, entities generally pass from sources 202 tosinks 208. Entities can, however, traverse numerous intermediate blocks204, 206 on the pathway from source 202 to sink 208. These intermediateblocks 204, 206 can be represented by numerous specialized DES blockswithin the block library of the present DES modeler.

These intermediate blocks can have the same functionality as describedabove for the sinks. For example, the intermediate blocks can displayall of the attributes passed to them, or can display a defined set ofvariables. The intermediate blocks can have conditions to define whichentities can pass through them. Scope Blocks can serve as intermediateblocks that accept an entity and plot data from the entity in agraphical manner. Display Blocks can also display selected attributes ofan entity. Furthermore, the intermediate blocks can include blocks thatexport a signal from the DES model to an external environment, or importa signal or other input information from an external environment.

FIG. 6 depicts an example of an intermediate block utilized inaccordance with one embodiment of the present invention. A Routing Block210 may be placed between two source blocks 201, 203 such that only asubset of entities is passed to a sink block 208. The subset isdetermined by the logic of the Routing Block 210 and the data that ituses to determine the path from which the entity is allowed to arrive.Additional intermediate blocks that can be used in accordance with thepresent invention include, but are not limited to Logical Gates, QueuingBlocks, Storage Blocks, Routing Blocks, Execution Control Blocks, ServerBlocks, Resource Allocation Blocks, Timer Blocks, Timeout Blocks, andDelay Blocks. Additionally, the DES environment allows for users tocustomize and define their own blocks specific to the problem they aremodeling and the model they have developed.

The path that an entity takes through the DES modeler environment, asdepicted in FIG. 6, is an entity path 212. The entity path 212 is anyconnection from an entity output port 214 to an entity input port 216 ona block within the DES modeler. For illustrative purposes, these entitypaths are represented by a line connecting the entity input 214 andoutput ports 216 of blocks within the DES model environment. The entitypath 212 in the DES model environment is active only when an entity ispassing through the entity path 212. At times when there is no entitypassing through the entity path 212 in the execution, the entity pathhas no value associated with it.

Further, there may be associated with each block in a DES environment astate, wherein the state is a persistent data set corresponding to theblock. The state variable of a block contains a set of attributesassociated with the block (i.e. a Boolean operation, string, parsablestring array) and may contain a sub state variable for nesting andcombining hierarchies.

Within the DES model of the present invention there can be numerousevents. Events are instantaneous occurrences that change a statevariable, an output, a future event or any combination thereof. Eventsare generated at any point at which a block within the DES model acts onan entity. Events can take numerous forms, but by example can includethe creation of a new data packet in a network, the exit of a packagefrom a loading dock or the placement of an item on a conveyor belt in amanufacturing plant. Each event within a DES model contains fourspecific characteristics associated with the event. Firstly, each eventspecifies an entity, namely a set of data associated with the event.Additionally, each event has time data associated with it, defining whenthe event is scheduled to occur. Events in a DES model can also have apriority associated with their execution, thereby defining the urgencyof the event relative to other events that may occur at the same time.Finally, each event has a destination object associated with it, whichserves to identify where the event is to take place. The destinationobject is typically a DES model block but can also be an entity.

In FIG. 7, a DES environment 200 is denoted. The DES model is capable ofcommunicating with external environments of various forms 230, 260, 270,280 including such examples application as Simulink® and Stateflow®. Inone embodiment, the DES model can receive data from these environments230 and 270 as well as output data to these external environments 260,280 in accordance with the needs of the user generating the model.Communication with the external environments 230, 270, 260, 280,however, is not necessary, as execution models may be created solelywithin DES environment that have no interface with environments beyondthe DES environment 200.

An entity generator within the DES environment 220 can interface with anexternal environment 230, such as Simulink®, at port “t” 240 on theentity generator 220. The entity generator block 220 is an example of asource block within DES. The signal transmitted on signal path 244 andreceived at port “t” 240 is used to control the rate of entitygeneration by the entity generator 220. Associated with the signal onsignal path 244 is a probability distribution provided by theExponential Interarrival Time Distribution (Simulink®) subsystem 242within the external environment 230. In light of this probabilitydistribution, a varying signal is presented to the entity generator 220resulting in the generation of entities in accordance with theprobability distribution of the Exponential Interarrival TimeDistribution (Simulink®) subsystem 242. Entities generated by the entitygenerator 220 are passed from the output port of the entity generator246 to the input port of the queue block 248 over the entity path 212.

The queue block 222 accepts entities and is capable of forwarding themto further associated blocks. In the present example, the entitiesgenerated by the entity generator 220 can be forwarded to the serverblock 224 by the queue block 222 in accordance with user defined values.For example, a user may instruct the queue to hold no more than 10entities for forwarding. When the queue block 222 has reached capacity,the input port to the queue block 248 may be temporarily disabledthereby preventing the introduction of any more entities to the queueblock 222. In such a scenario, the input port of the queue block 248 isdefined as unavailable. When the number of entities within the queueblock 222 has decreased below the 10 entity limit, the input port to thequeue block 248 can be made available, allowing the delivery ofadditional entities from the entity generator 220 to the queue block222. Entities within the queue block 222 can be queued based upon thetime at which they were generated by the entity generator 220, or can bequeued based upon numerous other arrangements. For example, a prioritymay be associated with various entities, and the queue block 222 mayqueue entities based upon their priority. Furthermore, as exhibited inFIG. 7, the queue block 222 may interface with an external environment260 outside of the DES model 200. As illustrated, the queue block 222has been associated with a scope 262, a first display 264 and a seconddisplay 266, thereby allowing a user to graphically view that which isoccurring within the queue block 222.

The queue block 222 of the illustrative embodiment can pass entitiesfrom the output port of the queue block 252 to an input port 254 of theassociated server block 224. The server block 224 can accept entitiesdelivered through the entity path 212 connecting the queue block output252 to the Server Block input port 254. The Server Block 224 can delay areceived entity for a time before passing it to the next associatedblock, namely the Terminator Block 226. The delay associated with aserver is known as a “service time”. Service time may be user-defined,or may be based upon an internally or externally generated value. Forexample, the example embodiment utilizes a Simulink® signal with anassociated probability distribution in the Exponential Service TimeDistribution with Rate 1 block 270. This results in a variable servicetime for the server block 224. This variable service time is provided tothe Server Block 224 at port 272 of the server block via a signal line244. While the server block 224 is busy, i.e. during the service time,the server block 224 will make its input port 254 unavailable, therebypreventing the reception of any additional entities. Upon expiration ofthe service time, the input port to the server block 254 will be madeavailable, thereby allowing the passage of entities once again.Simultaneously, once the service time is completed, the server can passentities from an output port of the server block 250 to a furtherassociated block. In the present example, this block is a terminatorblock 226, which is a sink within the DES environment. The terminatorblock 226 can be user-defined to accept all entities passed to it, ormay have other functionality defined by a user. For example, theterminator block 226 may be defined such that it blocks all entitiesdelivered to it, or may produce an error message upon the arriving of anentity. The server block 224 of the illustrated embodiment can furtherbe associated with an external environment 280 external to the DESmodel. As evidence in the example, the server block 224 can deliver asignal to a first graphical interface 282 and a second graphicalinterface 284 so that a user can monitor the internal operations of theServer block 224.

In a DES model environment, the DES solver is driven by ordered events,therefore time becomes a secondary variable in the execution. The orderof events within a DES model is continually updated in response tochanges in the model. Utilizing such an event-driven model, only thosepoints at which an event is scheduled to occur need to be modeled. Timebetween events, namely “empty time” need not be modeled, therebyresulting in improved efficiency and decreased processor demand.

Events within a DES model are scheduled and managed using an EventCalendar. Unlike a time-based modeling environment, size of the timeinterval between events is simply the period of time between events.Using the Event Calendar, the DES model can determine when to update thestates of certain block in the model, and can also infer when to savetime by not updating states. An example of the application of the EventCalendar is best seen by example.

FIG. 8 is an example DES model for use in describing the Event calendar.Assume that the blocks are configured so that the Entity Generator 300block generates an entity at various times, namely t=0.9 seconds, 1.7seconds, 3.8 seconds, 3.9 seconds, 6 seconds. Further assume that thequeue block 302 has a capacity of 20. Additionally, assume that theserver block 304 uses random service times that are uniformlydistributed between 0.5 seconds and 2.5 seconds. When the executionfirst starts, the queue block 302 and server block 304 are empty. Theentity generator block schedules a first event at t=0.9 s. Anillustrative example of the event calendar 900 at time t=0.9 isillustrated in FIG. 9. One skilled in the art will recognize that thedescribed parameters are merely illustrative of one example, and thatthe model can generate any suitable number of entities at any suitabletime, the queue block can have any suitable capacity and the serverblock can have any suitable service time.

At t=0.9 seconds, the entity generator block 300 of FIG. 8 creates anentity and attempts to output the entity from the entity generatoroutput 346. Because the queue block 302 is empty, the entity advancesfrom the entity generator block output 346 to the queue block input 348over the entity path 312 in the model. Since the queue block 302 has noentity within it, the queue block 302 attempts to output the entity tothe next block in the model, namely the server block 304. Because theserver block 304 is empty, the entity advances from the queue block 302to the server block 304. At this moment, the server's entity input port354 is temporarily unavailable to future entities.

Upon receiving the entity, the server block 304 schedules an event thatindicates when the entity's service time is completed. For the purposeof illustration, duration of service of 1.3 seconds is assumed. In lightof this, service will be completed at a time of t=2.2 seconds, the sumof the time that the entity enters the server, and the service time.

As set forth previously, a second entity generation event is scheduledat t=1.7 seconds. The event calendar and the associated DES model 903 ata time of t=1.7 seconds is depicted in FIG. 10. The updated EventCalendar 902 is shown, as well as a graphical representation of entitystatus within the DES model. In FIG. 10, the element marked “e1” 404signifies the first entity and the dashed arrow 906 serves to indicatethe advancement of the first entity 404 from the entity generator block300 to the queue block 302 and finally to the server block 304.

As evidenced in the Event Calendar at time t=1.7 seconds 902 of FIG. 10,a second entity is to be generated at a time of t=1.7 seconds.

FIG. 11 is an illustrative embodiment of the present invention at a timeof t=1.7 seconds 904. At a time of t=1.7 seconds the entity generatorblock 300 will create an entity “e2” 504 and will attempt to output it.The queue block 302 is empty at this point in time, so the second entity504 advances from the entity generator 300 to the queue 302 asillustrated in FIG. 11. The advance of the second entity 504 is depictedby the dashed arrow 506.

As depicted in FIG. 11, the newly generated entity “e2” 504 is the onlyone in the queue block 302. The queue block 302 will therefore attemptto output the second entity 504 to the server block 304. As entity e1404 remains in the server block 304, the server block's input port 354is unavailable to receive the second entity 504. The second entity 504will therefore remain in the queue block 302 until the server becomesavailable.

FIG. 12 is an illustrative example of the event calendar at a time oft=2.2 seconds 905. Based upon the original assumptions, the entitygenerator block will schedule the generation of a third entity (e3) at atime of t=3.8 seconds.

FIG. 13 is an illustrative embodiment of the present invention at a timeof t=2.2 seconds 906. At t=2.2 seconds, the server block 304 finishesserving the first entity 404 (i.e. service time is completed) andattempts to output the first entity 404 to the associated terminatorblock 306. The terminator block 306 is simply a sink that by definitionaccepts and absorbs all entities. In light of this, the first entity(e1) 404 advances from the server block 304 output port 356 to theterminator block 306 input port 358. As the first entity (e1) 404advances, the server block's 304 entity input port 354 becomes availableonce again, allowing the queue block 302 to pass the second entity (e2)504 to the server block 304 via the server block input port 354 via anentity path 212. Upon passing the second entity 504 to the server block304, the queue block 302 is now empty and the server block 304 becomesbusy again. As the server block 304 is busy, the server block's entityinput port 354 becomes temporarily unavailable once again.

FIG. 14 is a depiction of the Event Calendar at a time of t=3.8 seconds904. The event calendar at time t=3.8 seconds has been generated usingthe assumption that a service time of t=2.0 seconds has been establishedfor the second entity.

FIG. 15 is a graphical depiction of the DES model at a time of t=3.8seconds 905. At t=3.8 seconds, a third entity 604 will be generated bythe entity generator block 300. The queue block 302 remains empty, sothe third entity 604 advances from the entity generator 300 to the queueblock 302. The advancement of the third entity 604 from the entitygenerator 300 to the queue block 302 is illustrated by the dashed line606.

Because the third entity 604 is the only one in the queue block 302, thequeue block 302 will attempt to output the entity to the server block304. As set forth above, the server block's input port 354 remainsunavailable due to the presence of the second entity 504 in the serverblock 304, so the third entity 604 will remain in the queue block 302.The queue block's 302 entity output port 352 is said to be blockedbecause an entity has tried and failed to depart via this port.

FIG. 16 graphically represents the event calendar at a time of t=3.9seconds 906.

FIG. 17 is a graphical depiction of the present invention at a time oft=3.9 seconds 907. At t=3.9 seconds, the entity generator 300 schedulesthe generation of a fourth entity 704. The entity generator 300 willattempt to output the fourth entity 704 to the queue block 302. Sincethe queue block 302 is not full, the fourth entity 704 will advance fromthe entity generator block 300 to the queue block 302. The serverblock's entity input port 354 remains unavailable, therefore the queueblock 302 cannot output the fourth entity 704 to the server block 304.The queue length within the Queue Block 302 is two, as depicted in FIG.17.

FIG. 18 is a graphical depiction of the DES model 908 and event calendar909 at a time of t=4.2 seconds. At t=6.0 seconds, a fifth entity 804 isgenerated by the entity generator 300. At time t=4.2 the server block304 finishes serving the second entity 504 and attempts to output thesecond entity 504 to the terminator block 306. The terminator block 306accepts the second entity 504 and the second entity 504 advances fromthe server block 304 to the terminator block 306 via a entity path 212.Additionally, the server block's entity input port 354 becomesavailable, so the queue block's entity output port 352 becomesunblocked. The queue block 302 is now able to output the third entity604 to the server block 304. The queue length within the queue block 302has decreased to only one entity, namely the fourth entity 704, and theserver block 304 once again becomes busy. The server block's entityinput port 354 again becomes temporarily unavailable. The server block304 will schedule an event on the event calendar that indicates when theentity's service time is completed on the event calendar. Forillustrative purposes, 0.7 seconds will be used. The event calendar at atime of t=4.9 seconds 909 is presented in FIG. 19.

The queue block 302 will attempt to output the fourth entity 704, butthe server block's entity input port 354 is unavailable. In light ofthis, the fourth entity 704 remains in the queue block 302. At the sameinstant, the queue block's entity output port 352 becomes blocked,prohibiting further attempt to pass the fourth entity 704 to the serverblock 304 while the server block's input port 354 remains blocked.

Remaining entities within the illustrated model will pass through themodel in accordance with the above steps as driven by the eventcalendar. Additional entities may be placed on the calendar by theentity generator block 300, or no additional entities may be generatedand the execution will be complete upon the passage of the fifth entity804 to the terminator block.

The defined times on the event calendar are inherently important withinthe DES modeling systems, as events on the event calendar serve asindicators of times at which the systems state is changing. In contrast,times between events on the event calendar are not important to modelingthe system, in that at these times the system state remains unchanged.In light of this, the DES modeler skips the static periods and focus onthe event times of the event calendar. Such an arrangement offersincreased efficiency as compared to a fixed sampling interval.

Additionally, at defined times within the event calendar, multiplestates can change instantaneously. For example, at time t=2.2, theserver block 304 becomes idle and then busy again. Simultaneously, thequeue length also changes because the queue block 302 outputs a secondentity (e2) 504 to the server block 304.

The illustrative event calendar serves as a convenient example of eventprocessing at discrete time intervals within the model. Inherent inadvanced modeling of a system, however, is an occurrence of two or moreevents that are scheduled to occur at the same time instant. Such eventsare defined as “simultaneous” events and are depicted on a sample eventcalendar in FIG. 20. The sequential processing of these simultaneousevents may be irrelevant or relevant to the execution results, thereforethe DES modeler contains numerous methods for determining the properprocessing sequence. One such method is the assignment of prioritylevels to the events.

In FIG. 21, priority values 830, 832 are assigned to the simultaneousevents 820, 822 within the event calendar. The relative priorities amongthe simultaneous events therefore determine their processing sequencewithin the event calendar. Using a priority value associated withsimultaneous events allows a user to decide how various events arerelated to each other. However, this approach might be inappropriate ifa deterministic approach produces a bias that inaccurately reflects thephenomena that a user is modeling. In light of such concerns, a randomsequence may be utilized. The random sequence for executing simultaneousevents offers the advantage of eliminating bias in the execution, butresults in the non-repeatability of the execution should a user run theexecution more than once, assuming random number seeds are not utilized.

The DES model of the present invention allows for the transfer ofinformation to various block within the DES model environment, as wellas to environments outside of the DES model. For example, as indicatedin FIG. 7, the use of a terminator block as a sink may allow foracceptance of all entities within the model. In place of or inconjunction with the terminator block, a scope block may be utilized toaccept an entity and plot data from an attribute of the entity. Dataplotted may include a plot of information related to entitiesexperiencing a discrete event or a discrete state. Utilizing a scopeblock a user can visually verify the operation and performance of a DESmodel. Additionally, a display block may be associated with the DESmodel such that the value of an attribute of an entity is graphicallydisplayed. The DES model of the present invention further includesblocks that allow the export of entity attribute values to regionsoutside of the DES model environment. For example, individual entitypriority data may be exported to an external modeling environment suchas Simulink®. Control of export of data from this block can take placewithin the DES model environment, can be controlled by an externalenvironment, or can be a combination of both. In light of this, whenmodeling complex systems, the DES model of the present invention can beincorporated into other modeling, execution, and display applications.In the alternative, the DES model of the present invention can operatein a stand alone configuration, wherein a system to be modeled ismodeled solely within the DES model environment.

The present invention discloses a method and system for transferringdata between a discrete event system (DES) environment and a secondenvironment distinct from the DES environment. A broad overview of theintegration of both environments and the transfer of information betweenthese environments is illustrated in FIG. 22. FIG. 22 illustrates ahybrid model environment 900 wherein a DES environment operatessimultaneously with a second environment external to the DESenvironment. For illustrative purposes, entity paths 902 between DESblocks are denoted by connectors bearing diamond shaped endpoints. Anexample of such an entity path 902 can be seen between the output port901 of the entity generator 905 and the input port 908 of the BasicQueue block 907. These entity paths 902 only have data values when anentity is passing through them.

In contrast, data signals external to the DES environment are evidencedby signal paths 904 bearing an arrow shape. One of ordinary skill in theart will appreciate that the use of an arrow-shaped signal path ismerely representative and these signal paths can take the form ofnumerous other embodiments. An example of a signal path 904 is a datasignal within a time based model environment. The arrow indicates whichblocks read from the signal and write to the signal as the signal varieswith time. The variable nature of the signal in relation to time differsfrom the presence of data within an entity path 902 only when an entityis passing through it.

As illustrated in FIG. 22, the Basic Queue block 907 transfers both anentity over the entity path 902, as well as a data signal over the datasignal 904 path to the Set Count Attribute block 909. The hybridcombination of both a DES model as well as an alternative environmentthat is not a discrete event system offers a user the ability to analyzea dynamic system with the most appropriate tools necessary for the modelevaluation, as opposed to being restricted by the constraints of asingle model environment.

FIG. 23 depicts a more detailed view of one example embodiment of thepresent invention. In particular, the inner workings of the Basic Queueblock 907 are detailed, such that a gateway block 920, which providesfor the transfer of information from the DES environment to an externalenvironment, is depicted. The basic queue block 907 receives an entityat the input to the basic queue block 908 over the entity path 902. Thebasis queue block 907 can then pass this entity, or attributes relatingto this entity, to another block within the block diagram model via thebasic queue output port 910. The basic queue block can further pass theentity, or attributes relating to the entity, to a gateway port 912 onthe basic queue block 907. The port 912 associated with the gatewayblock 920 allows for the passage of attribute information relating tothe entity, via an entity path 902, to a gateway block 920 of thepresent invention. This gateway block 920 receives an entity attributein the DES environment and converts this attribute into a data signal904 capable of being utilized in an external model environment. In thepresent embodiment of FIG. 23, the gateway block 920 receives an entityattribute at the input port 918 of the gateway block via an entity path902. The gateway block 920 is capable of bridging the timing and datamanagement semantics between the DES environment of the block diagrammodel, and the requirements of the external environment in which thedata signal is to be used.

In the present embodiment the gateway port 912 reports the number ofentities that are currently stored in the basic queue block 907. Thenumber of entities is updated upon successful arrival of an entity viathe input port 908 and successful sending of an entity via the outputport 910. The gateway port 912 of the present embodiment wherein thegateway port 912 outputs the number of entities within the basic queueblock 907 is representative of data that may be provided to a gatewayblock 920. Additional data that may be provided to a gateway block 920,includes but is not limited to statistical data relating to the numberof entities that have departed the basic queue block 907, the averagewait time for entities within the basic queue block 907 or the status ofthe output port of the basic queue block 907, namely block or unblocked.Statistical data relating to the number of entities that have departedthe basic queue block 907, and the average wait time for entities withinthe basic queue block 907 is updated upon departure of an entity fromthe basic queue block 907. The status of the output port of the basisqueue block 907 is updated following an attempt to send an entity aswell as departure of an entity from the basis queue block 907 using anoptimization technique specific to the requirements of the externalenvironment. For example, a conditional execution context can be usedwhen the external environment is a Simulink® environment. Using aconditional execution context, the simulation speed of the model isincreased as execution of blocks that are not specifically required forexecution of the model may the avoided. The determination of whichblocks do not require execution in a mode can be automaticallyconfigured, manually configured, or some combination of both.

At compile time of a Simulink® model using a conditional executioncontext, each block in the model is evaluated to determine whether itsoutput is required only by a conditionally executed subsystem or itsinput changes only as a result of the execution of a conditionallyexecuted subsystem. If a block meets these conditions, and the modelprovides for execution context propagation across blocks within themodel, Simulink® can move the block into the execution context of thesubsystem. This ensures that the block's methods are executed during thesimulation loop only when the corresponding conditionally executedsubsystem executes. Furthermore, using the conditional executioncontext, a mechanism is provided wherein blocks in the externalSimulink® environment can be executed immediately after the update ofthe values associated with blocks contained within the externalSimulink® environment.

The use of a conditional execution context environment within aSimulink® model has been used for illustrative purposes, and is notintended to serve as the only means by which efficiency of executionwithin a simulation can be enhanced. On skilled in the art will readilyrecognize that numerous alternative forms of simulation processingenhancements may be employed in conjunction with the present invention.

The gateway block then produces a data signal at output port 919 that iscapable of being delivered to an external environment via a data signalpath 904. The data signal passed to the external environment can have avalue that is the same as the attribute value within the DESenvironment, or can have a modified value as compared to the entityattribute value within the DES environment. In one embodiment, this datasignal 904 can be passed to a time based model for subsequent analysisor display. In an alternate embodiment, the data signal can be passed toa data flow based model in which dataflow is mapped to time. Thoseskilled in the art will readily recognize that the data signal passedfrom the gateway block in the DES environment can be further passed toany external environment wherein the signal is beneficial in analyzingthe dynamic system at issue.

FIG. 24A, illustrates an alternative embodiment of the presentinvention. In FIG. 24A the set attribute block 909 of FIG. 22 isdepicted in greater detail. The set attribute block is capable ofreceiving an entity through entity path 902 at an input port 914. Theset attribute block 909 can forward the entity via output port 916. Theset attribute block 909 can further receive a data signal 904 from anexternal environment. This data signal 904 is first received at an inputport 922 of the gateway block 920. This data signal 904 originates in anon-DES environment, and those of ordinary skill in the art willrecognize that the data signal 904 may take numerous forms. For example,the data signal 904 can take the form of a data flow dependent signal ora time dependent signal. Examples of external environments capable ofgenerating an appropriate data signal are represented by, but notlimited to, Stateflow® and Simulink® by the MathWorks of Natick, Mass.In the present example, the attributes associated with an entity that isreceived via the entity path 902 at the input port 914 of the getattribute block 909 can be modified based upon data received from theexternal environment by the gateway block 920.

FIG. 24B of the present invention illustrates the modification of theattributes associated with an entity based upon a system model. In FIG.24B an entity generator 950 generates an entity and passes said entityto a first set attribute block 952 via an entity path 902. Furtherassociated with the first set attribute block 952 is a convert block 949that can change the data type of the time-driven signal in the externalenvironment. The first set attribute block 952 can convert a data signalfrom an external environment 904 for use with the DES model environmentusing a gateway block (not shown) A gateway block can be associated withany applicable blocks within the DES model environment, such that theintegration of an external data signal into the DES environment iscompleted without the need for a user to manually configure a gatewayblock. The presence of a gateway block with a DES block, therefore, isnot immediately depicted on a DES model illustrated in FIG. 24B, butshould a user elect to examine any DES block more closely, theassociated gateway block for use in interacting with the externalenvironment can be examined. In the present embodiment, the externalenvironment 951 is a free running counter. The first set attribute block952 passes entity data to a first get attribute block 954 via an entitypathway 902. Associated with the first get attribute block 954 is ascope block 956, wherein the scope block graphically plots datacontained within the first set attribute block 952. An illustrate plotof data contained within the first set attribute block 952 isgraphically depicted in FIG. 24C, wherein priority is plotted as afunction of time.

The first get attribute block 954 further passes an entity to a secondset attribute block 958. Associated with the constant block 960 locatedin an external environment. Signal data from the constant block 960 isprovided to the second set attribute block 958. The second set attributeblock 958 can have an embedded gateway block associated with the secondset attribute block as depicted in FIG. 24A. Data contained within thesecond get attribute block 961 is graphically displayed on a secondscope block 962. A graphical depiction of the data plotted by the secondscope block is depicted in FIG. 24D. As evidenced in FIG. 24D, followingthe introduction of a constant from a constant block 960 in the externalenvironment, the attributes of entities contained within the second setattribute block 958 are altered.

Furthermore, as evidenced in FIG. 24A, the gateway block may assign andgenerate a new attribute, to be associated with a passing entity, basedupon data received from the external environment. If the gateway block920 receives a data signal 904 from an external environment that resultsin the production of an entity attribute that is not recognized by theset attribute block 909, the set attribute block 909 can either createthe attribute and assign the new value, or can create the attribute andassign a new value, while simultaneously warning the user that anunexpected input from the external environment has been received.

FIG. 25 illustrates a representative embodiment of the present inventionwhen used with a time based model source signal. An entity generator1000 receives a data signal 904 through a gateway block 920. The gatewayblock of the present embodiment is capable of converting a data signalreferenced to a time based model sample time into an entity for use witha DES model. In the present embodiment, for instance, a signal to createa new entity is passed from the gateway block 920 to the entitygenerator 1000 at a rate which coincides with the sample time of thetime based model.

FIG. 26 illustrates an alternate embodiment of the present inventionwhen used in conjunction with a time driven model environment thatprovides a trigger signal. Those skilled in the art will recognize thatthe trigger signal in the external environment can take numerous formsbeyond a time driven model environment trigger signal. In response tothe reception of a trigger signal from an external environment, such asStateflow®, the gateway block 920 can communicate with an entitygenerator 1002 via an entity path 902, thereby instructing the entitygenerator to generate a new entity. This new entity can then beintroduced into the DES model via the entity generator output port 1004.In the present embodiment, a new entity will only be generated uponreceiving a trigger signal from the external environment. To determineif a trigger signal is present an initial trigger signal value will bestored. The triggering of the entity generator will therefore occur uponreception of a secondary signal that is greater than the initial signal,less than the initial signal, or greater than or less than the initialsignal.

The gateway block 920 of the present invention can further be utilizedin interfacing an external environment to a DES environment based uponthe execution of a function call 1006 in the external environment. Sucha situation is illustrated in FIG. 27A. A function call 1006 in theexternal environment can be passed to the entity generator 1004 blockthrough a gateway block (not shown) associated with the entity generatorblock through a gateway block. Those skilled in the art will appreciatethat DES block can have embedded gateway blocks for communication withan external environment. An embedded gateway block such as this allows auser to send and receive data to or from an external environment withoutneeding to manually configure a standalone gateway block for use withthe DES environment.

The embedded gateway block (not shown) associated with the entitygenerator is used in interfacing an external environment to a DESenvironment upon execution of a function call in the externalenvironment uses the semantics of the external environment to generatean entity by the entity generator 1004. The processing of a functioncall 1006 in the external environment, therefore, can instruct theentity generator 1004 to generate an entity for use in the DES modelenvironment.

As illustrated in FIG. 27B, an entity generator 1004 in the DESenvironment can call a function call in a function call subsystem 1005in an external environment. The interaction between the DES environmentand function call subsystem in the external environment 1005 can occurusing a gateway block (not shown) associated with the DES environment.The calling of a function in the external environment does not requirethe passage of data from the DES model environment, but rather passes aninstruction for use in calling a function in the external environment.

Gateway blocks in accordance with the present invention can beassociated with numerous blocks beyond those illustrated in the figures.A user of a DES block diagram model can associate a gateway block withany existing DES model environment block such that the intended dynamicmodel execution is best analyzed using both the DES environment as wellas a non-DES external environment. For example, a DES block diagrammodel can have a Set Attribute block associated with a gateway blocksuch that an external data signal from a non-DES environment can beutilized in generating a modified entity.

FIG. 28 illustrates an alternate embodiment of the present inventionwherein a block, namely a basic server block 1100, within the blockdiagram model environment is associated with a plurality of gatewayblocks 1102, 1104. These gateway blocks 1102, 1004 provide for theinterface of a data signal into the DES environment, as well as thetransfer of a data signal from the DES environment.

FIG. 29 is an example embodiment of an electronic device 1500 suitablefor practicing the illustrative embodiments of the present invention.The electronic device 1500 is representative of a number of differenttechnologies, such as personal computers (PCs), laptop computers,workstations, personal digital assistants (PDAs), Internet appliances,cellular telephones, and the like. In the illustrated embodiment, theelectronic device 1500 includes a central processing unit (CPU) 1502 anda display device 1504. The display device 1504 enables the electronicdevice 1500 to communicate directly with a user through a visualdisplay. The electronic device 1500 further includes a keyboard 1506 anda mouse 1508. Other potential input devices not depicted include astylus, trackball, joystick, touch pad, touch screen, and the like. Theelectronic device 1500 includes primary storage 1510 and secondarystorage 1512 for storing data and instructions. The storage devices 1510and 1512 can include such technologies as a floppy drive, hard drive,tape drive, optical drive, read only memory (ROM), random access memory(RAM), and the like. Applications such as browsers, JAVA virtualmachines, and other utilities and applications can be resident on one orboth of the storage devices 1510 and 1512. The electronic device 1500can also include a network interface 1514 for communicating with one ormore electronic devices external to the electronic device 1500 depicted.A modem is one form of network interface 1514 for establishing aconnection with an external electronic device or network. The CPU 1502has either internally, or externally, attached thereto one or more ofthe aforementioned components. In addition to applications previouslymentioned, modeling applications can be installed and operated on theelectronic device 1500.

It should be noted that the electronic device 1500 is merelyrepresentative of a structure for implementing the present invention.However, one of ordinary skill in the art will appreciate that thepresent invention is not limited to implementation on only the describeddevice 1500. Other implementations can be utilized, including animplementation based partially or entirely in embedded code, where nouser inputs or display devices are necessary. Rather, a processor cancommunicate directly with another processor or other device.

The illustrative embodiment has been described solely for illustrativepurposes relative to the technical computing environment of MATLAB® andSimulink® from The MathWorks, Inc. of Natick, Mass. Although theillustrative embodiment will be described relative to a MathWorks-basedapplication, one of ordinary skill in the art will appreciate that thepresent invention may be applied to other graphical modelingenvironments and technical computing environments, such as any technicalcomputing environments using software products of LabVIEW®, MATRIXx fromNational Instruments, Inc., Mathematica® from Wolfram Research, Inc.,Mathcad of Mathsoft Engineering & Education Inc., Dymola from DynasimAB, or Maple™ from Maplesoft, a division of Waterloo Maple Inc.Furthermore, one ordinarily skilled in the art will appreciate that thepresent invention may apply to any graphical modeling environment, suchas one providing modeling with a Unified Modeling Language (UML),Hardware Description Language (HDL), or that provides a physics modelingdomain.

The present invention has been described by way of example, andmodifications and variations of the described embodiments will suggestthemselves to skilled artisans in this field without departing from thespirit of the invention. Aspects and characteristics of theabove-described embodiments may be used in combination. The describedembodiments are merely illustrative and should not be consideredrestrictive in any way. The scope of the invention is to be measured bythe appended claims, rather than the preceding description, and allvariations and equivalents that fall within the range of the claims areintended to be embraced therein.

1. A method of transferring data between a plurality of modelenvironments, comprising the steps of: providing a first environment,wherein said first environment comprises an event driven discrete eventmodel environment supporting at least one entity that passes through thediscrete event model environment holding at least one value of arbitrarydata type and in which the entity definition can be altered at run time;providing a second environment, wherein said second environment isdistinct from said first environment; and implementing a gatewayinterface in said discrete event model environment, wherein said gatewayinterface modifies data compatible with the discrete event modelenvironment to be compatible with the second environment.
 2. The methodof claim 1, wherein the execution of events within the first environmentis controlled by an event calendar.
 3. The method of claim 1, whereinthe second environment is a time based model environment.
 4. The methodof claim 1, wherein the second environment is a state based modelenvironment
 5. The method of claim 1, wherein the second environment isa dataflow based model environment.
 6. The method of claim 1, whereinthe gateway interface further comprises an optimization techniquespecific to the second environment, wherein the optimization techniqueoptimizes the transfer of data between the discrete event modelenvironment and the second environment.
 7. The method of claim 6,wherein the optimization technique uses a conditional execution contextfor optimizing the transfer of data between the discrete event modelenvironment and the second external environment.
 8. The method of claim1, wherein the first environment further comprises entity dataassociated with the discrete event model environment.
 9. The method ofclaim 8, wherein entity data further comprises an attribute setassociated with the entity data.
 10. The method of claim 9, wherein theattribute set further comprises a field associated with the entity data.11. The method of claim 8, wherein the first environment furthercomprises sub-entity data.
 12. The method of claim 1, further comprisingthe step of transferring data between the gateway interface and thesecond environment over a signal path.
 13. The method of claim 1,further comprising the step of transferring data from the gatewayinterface to the first environment over an entity path.
 14. The methodof claim 12, wherein data transferred between the gateway interface andthe second environment over the signal path has the same value as datawithin the first environment.
 15. The method of claim 12, wherein datatransferred between the gateway interface and the second environmentover the signal path is modified relative to data within the firstenvironment.
 16. The method of claim 13, further comprising the step ofgenerating a new attribute and assigning a new attribute value basedupon data received from the gateway interface and transferred to thefirst environment over an entity path that is not recognized by thegateway block.
 17. The method of claim 16, further comprising the stepof generating a warning indicating the reception of data not recognizedby the gateway block.
 18. The method of claim 1, further comprising thestep of generating a trigger, wherein said trigger generates thecreation of a new entity for use within the first environment.
 19. Themethod of claim 1, further comprising the step of generating a Simulinkfunction call, wherein said function call generates the creation of anew entity for use within the first environment.
 20. The method of claim1, further comprising the step of generating an enable signal, whereinsaid enable signal generates the creation of a new entity for use withinthe first environment.
 21. The method of claim 1, further comprising thestep of generating a trigger, wherein said trigger controls theoperation of the model components in the first environment.
 22. Themethod of claim 1, further comprising the step of generating an enablesignal, wherein said enable signal controls the operation of the modelcomponents in the first environment
 23. The method of claim 1, furthercomprising the step of generating a trigger, wherein said triggercontrols the operation of the model components in the first environment.24. A system for transferring data between a plurality of modelenvironments, said system comprising: a first model environment, whereinsaid first model environment is a discrete event environment, a secondmodel environment, wherein the second model environment is distinct fromthe first model environment, and a gateway interface, wherein saidgateway interface is in communication with the first model environmentand the second model environment such that data can be transferredbetween said first and second model environments.
 25. The system ofclaim 24, wherein the first model environment further comprises an eventcalendar for controlling the execution of events within the firstenvironment.
 26. The system of claim 24 herein the second environment isa time based model environment.
 27. The system of claim 24, wherein thesecond environment is a state based model environment
 28. The system ofclaim 24, wherein the second environment is a dataflow based modelenvironment.
 29. The system of claim 24, wherein the gateway interfacefurther comprises an optimization technique specific to the secondenvironment, wherein the optimization technique optimizes the transferof data between the discrete event model and the second environment. 30.The system of claim 29, wherein the optimization technique uses aconditional execution context for optimizing the transfer of databetween the discrete event model environment and the second externalenvironment.
 31. The system of claim 29, wherein the first environmentfurther comprises entity data associated with the discrete event modelenvironment.
 32. The system of claim 29 wherein entity data furthercomprises an attribute set associated with the entity data.
 33. Thesystem of claim 29, wherein the attribute set further comprises a fieldassociated with the attribute data.
 34. The system of claim 29, whereinthe first environment further comprises sub-entity data.
 35. The systemof claim 29, further comprising a transfer mechanism for transferringdata between the gateway interface and the second environment over asignal path.
 36. The system of claim 29, further comprising a transfermechanism for transferring data from the gateway interface to the firstenvironment over an entity path.
 37. The system of claim 36, whereindata transferred between the gateway interface and the secondenvironment over the signal path has the same value as data within thefirst environment.
 38. The system of claim 36, wherein data transferredbetween the gateway interface and the second environment over the signalpath is modified as compared to data within the first environment. 39.The system of claim 36, wherein a new attribute is generated andassigned a new attribute value based upon data received from the gatewayinterface and transferred to the first environment over an entity paththat is not recognized by the gateway block.
 40. The system of claim 39,wherein a warning is generated, said warning indicating the reception ofdata not recognized by the gateway block.
 41. The system of claim 39,further comprising the step of generating a trigger, wherein saidtrigger generates the creation of a new entity for use within the firstenvironment.
 42. The system of claim 24, further comprising the step ofgenerating a Simulink function call, wherein said function callgenerates the creation of a new entity for use within the firstenvironment.
 43. The system of claim 24, further comprising the step ofgenerating a enable signal, wherein said enable signal generates thecreation of a new entity for use within the first environment.
 44. Thesystem of claim 24, further comprising the step of generating a trigger,wherein said trigger controls the operation of the model components inthe first environment.
 45. The system of claim 24, further comprisingthe step of generating a enable signal, wherein said enable signalcontrols the operation of the model components in the first environment46. The system of claim 24, further comprising the step of generating atrigger, wherein said trigger controls the operation of the modelcomponents in the first environment.
 47. An interface mechanism fortransferring data between a discrete event model and a distinctenvironment, wherein said interface comprises: a gateway block, whereinsaid gateway block is in communication with a block within said discreteevent model and said external environment, and a conversion utilityassociated with the gateway block, wherein said conversion utilityproduces a compatible signal for use in establishing communicationbetween the discrete event model and the distinct environment.
 48. Theinterface mechanism of claim 47, wherein said block diagram modelenvironment is a discrete event driven model environment.
 49. Theinterface mechanism of claim 47, wherein said compatible signal is adiscrete event model signal having an entity associated with it.
 50. Theinterface mechanism of claim 47, wherein said compatible signal is aSimulink® signal.
 51. The interface mechanism of claim 47, wherein saidcompatible signal has a value with an associated sample rate.
 52. Theinterface mechanism of claim 47, wherein said gateway block communicatedwith said block diagram over an entity path.